perm filename STREAM[P,JRA] blob sn#481897 filedate 1979-10-18 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	the list of strings LOS idea is  essentially what is called a stream,  and
C00007 ENDMK
CāŠ—;
the list of strings LOS idea is  essentially what is called a stream,  and
probably a unix pipe/port, for that matter.

The scheme will be most  useful for defining objects  which we can use  as
windows. and at least as important: we MUST extend to having multi-processes
this is a key vehicle for that extension.

here's the idea:  objects  (characters for now) in  the stream are  either
real or  virtual; for  example,  when we  suck on  a  LOS connected  to  a
terminal and the  stream goes dry,  we expect  to go into  a listen  loop,
waiting for more  characters. these are  "virtual characters", defined  by
having a function (e.g. REACDH) defined as part of the FCB for the LOS. Of
course the standard  mechanizm for reading  form a traditional  file is  a
simple subcase:   inbuf goes empty => poke the disc.

to be a complete  logical item we need to be able to append crap to the 
end of a LOS as someone  else is sucking on the teat.


so a LOSy FCB should have at least:

1)pointer to the beginning of the "real" LOS  (if there is any)
2)pointer to the current reading position in the real LOS
3)pointer to the end of the read LOS 
4)a fun-obj to tell what to do when OUT of INput 

and maybe,
5)a fun-obj to tell  what to do when INundated with OUTput.

here for  example is  a way  of handling  the backspace  problem,  without
duplication of the reader.  BY THE WAY! backspace is STILL a problem  only
for terminal  streams; it  should NOT  be buried  in the  parser, and  the
following is a solution to that problem.

A) the character-reading  object associated  with a LOS  (entry #4  above)
contains a (THROW BS bla-de-bla) when it sees a backspacing character.  if
the character is NOT a bs, it is  "real"-ized by putting it on the end  ot
the read LOS,  appropriately updating  the pointers.   NB! this  character
reader echos what it snarfed.


B) riding on top of this is our corresponding CATCH-er; its basic body  is
a call  on  PARSE.  If  no  BS-trhow occurs  the  value  returned  is  the
internalized S-expr;  a BS-throw  is simple:  erase from  the screen,  the
necessary character, OR  ATOM, OR SEXPR,  or ...;appropriately modify  the
LOS pointers, and point the LOS at the (CATCH (PARSE LOS)) again.  Usually
now there will  be a "real"  LOS, and that  will be reparsed  back to  the
point of the bs; (NB WITHOUT ECHO-ing!). The LOS is a multitudinous win!!

what this says is that the BS catcher should also be associated as a funobj
of a LOS FCB.

The major hassle here is the free-space hunger of the reparse phase;  that
can be controlled  (i believe)  by automatic  reclamation of  intermediate
CONSery. Regardless, i think it  is the right way  to do it: backspace  is
generalized, OUT  OF THE  PARSER, it  is the  basis on  which to  build  a
display editor, and is the right kind of logical structure for windows.

					john allen  oct 18,1979